Merge version 1.0.11-1+rpi1 and 1.0.13-1 to produce 1.0.13-1+rpi1

Merge libde265 (1.0.13-1) import into refs/heads/workingbranch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.13-1) unstable; urgency=medium

  * New upstream version 1.0.13
  * Fixes CVE-2023-47471 (Closes: #1056187), CVE-2023-43887.
  * Update patches for new upstream version.
  * d/control: Upstream switched examples to SDL2 (Closes: #1038097).
  * Update symbols for new upstream version.

[dgit import unpatched libde265 1.0.13-1]

Import libde265_1.0.13.orig.tar.gz

[dgit import orig libde265_1.0.13.orig.tar.gz]

Import libde265_1.0.13-1.debian.tar.xz

[dgit import tarball libde265 1.0.13-1 libde265_1.0.13-1.debian.tar.xz]

Merge libde265 (1.0.12-2) import into refs/heads/workingbranch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.12-2) unstable; urgency=medium

  * Team upload
  * Clean Makefiles (Closes: #1047354)

  [ Vladimir Petko ]
  * add libde265 decoder smoke test (Closes: #1052214)

[dgit import unpatched libde265 1.0.12-2]

Import libde265_1.0.12-2.debian.tar.xz

[dgit import tarball libde265 1.0.12-2 libde265_1.0.12-2.debian.tar.xz]

Merge libde265 (1.0.12-1) import into refs/heads/workingbranch

Import libde265_1.0.12.orig.tar.gz

[dgit import orig libde265_1.0.12.orig.tar.gz]

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.12-1) unstable; urgency=medium

  * New upstream version 1.0.12
  * Fixes CVE-2023-27102, CVE-2023-27103

[dgit import unpatched libde265 1.0.12-1]

Import libde265_1.0.12-1.debian.tar.xz

[dgit import tarball libde265 1.0.12-1 libde265_1.0.12-1.debian.tar.xz]

Merge version 1.0.9-1.1+rpi1 and 1.0.11-1 to produce 1.0.11-1+rpi1

Merge libde265 (1.0.11-1) import into refs/heads/workingbranch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.11-1) unstable; urgency=medium

  [ Tobias Frost ]
  * Make my patch less noisy.

  [ Joachim Bauch ]
  * New upstream version 1.0.11
  * Unpackaged upstream version 1.0.10 fixes the following CVEs, most caused
    by the same underlying issue:
    CVE-2020-21594, CVE-2020-21595, CVE-2020-21596, CVE-2020-21597,
    CVE-2020-21598, CVE-2020-21599, CVE-2020-21600, CVE-2020-21601,
    CVE-2020-21602, CVE-2020-21603, CVE-2020-21604, CVE-2020-21605,
    CVE-2020-21606, CVE-2022-1253, CVE-2022-43236, CVE-2022-43237,
    CVE-2022-43238, CVE-2022-43239, CVE-2022-43240, CVE-2022-43241,
    CVE-2022-43242, CVE-2022-43243, CVE-2022-43244, CVE-2022-43245,
    CVE-2022-43248, CVE-2022-43249, CVE-2022-43250, CVE-2022-43252,
    CVE-2022-43253, CVE-2022-47655
  * Remove patch applied upstream.
  * Update patches for new upstream version.
  * Remove copyright entry for file no longer present in upstream.
  * Update symbols for new upstream version.
  * Bump "Standards-Version" to 4.6.2

[dgit import unpatched libde265 1.0.11-1]

Import libde265_1.0.11.orig.tar.gz

[dgit import orig libde265_1.0.11.orig.tar.gz]

Import libde265_1.0.11-1.debian.tar.xz

[dgit import tarball libde265 1.0.11-1 libde265_1.0.11-1.debian.tar.xz]

Merge version 1.0.9-1+rpi1 and 1.0.9-1.1 to produce 1.0.9-1.1+rpi1

Merge libde265 (1.0.9-1.1) import into refs/heads/workingbranch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Add visibility.m4 from upstream which is missing in the

Forwarded: https://github.com/strukturag/libde265/pull/355

release tarball.
===================================================================

Gbp-Pq: Name m4-visibility.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.9-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Apply patches to mitigate asan failures:
    reject_reference_pics_from_different_sps.patch and
    use_sps_from_the_image.patch.
  * Combined, this two patches fixes:
    - CVE-2022-43243, CVE-2022-43248, CVE-2022-43253 (Closes: #1025816)
    - CVE-2022-43235, CVE-2022-43236, CVE-2022-43237, CVE-2022-43238,
      CVE-2022-43239, CVE-2022-43240, CVE-2022-43241, CVE-2022-43242,
      CVE-2022-43244, CVE-2022-43250, CVE-2022-43252 (Closes: #1027179)
    - CVE-2022-47655
  * Additional patch recycle_sps_if_possible.patch to avoid over-rejecting
    valid video streams due to reject_reference_pics_from_different_sps.patch.
  * Modifying past changelog entries to indicate when vulnerabilities were
    fixed:
    - In 1.0.9-1, in total 11 CVE's. see #1004963 and #1014999
    - In 1.0.3-1, 1 CVE, see #1029396
  * drop unused Build-Depends: libjpeg-dev, libpng-dev and libxv-dev
    (Closes: #981260)

[dgit import unpatched libde265 1.0.9-1.1]

Import libde265_1.0.9-1.1.debian.tar.xz

[dgit import tarball libde265 1.0.9-1.1 libde265_1.0.9-1.1.debian.tar.xz]

Merge version 1.0.8-1+rpi1 and 1.0.9-1 to produce 1.0.9-1+rpi1

Merge libde265 (1.0.9-1) import into refs/heads/workingbranch

Import libde265_1.0.9.orig.tar.gz

[dgit import orig libde265_1.0.9.orig.tar.gz]

Add visibility.m4 from upstream which is missing in the

Forwarded: https://github.com/strukturag/libde265/pull/355

release tarball.
===================================================================

Gbp-Pq: Name m4-visibility.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.9-1) unstable; urgency=medium

  * Add "Rules-Requires-Root: no".
  * New upstream version 1.0.9
  * Remove patches now part of upstream release.
  * Bump "Standards-Version" to 4.6.1
  * Add patch to provide "gl_VISIBILITY" macro.
  * Update symbols for new upstream version.

[dgit import unpatched libde265 1.0.9-1]

Import libde265_1.0.9-1.debian.tar.xz

[dgit import tarball libde265 1.0.9-1 libde265_1.0.9-1.debian.tar.xz]

Merge libde265 (1.0.8-1.1) import into refs/heads/workingbranch

[PATCH] fix check for valid PPS idx (#298)

Gbp-Pq: Name 0006-CVE-2021-35452.patch

[PATCH] fix streams where SPS image size changes without refreshing PPS (#299)

Gbp-Pq: Name 0005-CVE-2021-36408.patch

[PATCH] fix assertion when reading invalid scaling_list (#300)

Gbp-Pq: Name 0004-CVE-2021-36409.patch

[PATCH] fix MC with HDR chroma, but SDR luma (#301)

Gbp-Pq: Name 0003-CVE-2021-36410.patch

[PATCH] fix reading invalid images where shdr references are NULL in part of the image (#302)

Gbp-Pq: Name 0002-CVE-2021-36411.patch

[PATCH] error on out-of-range cpb_cnt_minus1 (oss-fuzz issue 27590)

Gbp-Pq: Name 0001-CVE-2022-1253.patch

[PATCH] fill 32x32 scaling matrices

Gbp-Pq: Name 0001-fill-32x32-scaling-matrices.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.8-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Import upstream fixes for CVE-tracked vulnerabilities
    (Closes: #1014977)
    - CVE-2022-1253
    - CVE-2021-36411
    - CVE-2021-36410
    - CVE-2021-36409
    - CVE-2021-36408
    - CVE-2021-35452

[dgit import unpatched libde265 1.0.8-1.1]

Import libde265_1.0.8-1.1.debian.tar.xz

[dgit import tarball libde265 1.0.8-1.1 libde265_1.0.8-1.1.debian.tar.xz]

Merge version 1.0.7-1+rpi1 and 1.0.8-1 to produce 1.0.8-1+rpi1

Merge libde265 (1.0.8-1) import into refs/heads/workingbranch

Import libde265_1.0.8.orig.tar.gz

[dgit import orig libde265_1.0.8.orig.tar.gz]

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.8-1) unstable; urgency=medium

  * Update to debhelper compat level 13 and add debian/not-installed
  * Imported Upstream version 1.0.8
  * Remove patch applied upstream.
  * Bump "Standards-Version" to 4.5.1

[dgit import unpatched libde265 1.0.8-1]

Import libde265_1.0.8-1.debian.tar.xz

[dgit import tarball libde265 1.0.8-1 libde265_1.0.8-1.debian.tar.xz]

Merge version 1.0.4-1+rpi1 and 1.0.7-1 to produce 1.0.7-1+rpi1

Merge libde265 (1.0.7-1) import into refs/heads/workingbranch

[PATCH] Import "en265.h" to get correct name mangling of exported functions.

Without the header, "C++" name mangling will be used instead of the
required "C" names.

Gbp-Pq: Name fix_exported_symbols.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.7-1) unstable; urgency=medium

  [ Debian Janitor ]
  * Set upstream metadata fields: Bug-Submit.

  [ Joachim Bauch ]
  * Imported Upstream version 1.0.7
  * Update patches for new upstream version.
  * Update symbols for new upstream version.
  * Bump "Standards-Version" to 4.5.0

[dgit import unpatched libde265 1.0.7-1]

Import libde265_1.0.7.orig.tar.gz

[dgit import orig libde265_1.0.7.orig.tar.gz]

Import libde265_1.0.7-1.debian.tar.xz

[dgit import tarball libde265 1.0.7-1 libde265_1.0.7-1.debian.tar.xz]

Merge version 1.0.3-1+rpi1 and 1.0.4-1 to produce 1.0.4-1+rpi1

Merge libde265 (1.0.4-1) import into refs/heads/workingbranch

ffmpeg_2.9

Gbp-Pq: Name ffmpeg_2.9.patch

disable_tools

Gbp-Pq: Name disable_tools.patch

only_export_decoder_api

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.4-1) unstable; urgency=medium

  [ Ondřej Nový ]
  * Use debhelper-compat instead of debian/compat

  [ Joachim Bauch ]
  * Imported Upstream version 1.0.4
  * Enable hardening.
  * Specify Build-Depends-Package in symbols.
  * Ignore more internal STL symbols.
  * Bump "Standards-Version" to 4.4.1
  * Update to debhelper compat level 12.

  [ Debian Janitor ]
  * Set upstream metadata fields: Bug-Database, Repository, Repository-
    Browse.

  [ Sebastian Ramacher ]
  * debian/rules: Remove obsolete dh_strip override

[dgit import unpatched libde265 1.0.4-1]

Import libde265_1.0.4.orig.tar.gz

[dgit import orig libde265_1.0.4.orig.tar.gz]

Import libde265_1.0.4-1.debian.tar.xz

[dgit import tarball libde265 1.0.4-1 libde265_1.0.4-1.debian.tar.xz]

Merge version 1.0.2-2+rpi1 and 1.0.3-1 to produce 1.0.3-1+rpi1

Merge libde265 (1.0.3-1) import into refs/heads/workingbranch

ffmpeg_2.9

Gbp-Pq: Name ffmpeg_2.9.patch

disable_tools

Gbp-Pq: Name disable_tools.patch

only_export_decoder_api

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.3-1) unstable; urgency=medium

  [ Ondřej Nový ]
  * d/copyright: Use https protocol in Format field
  * d/control: Set Vcs-* to salsa.debian.org

  [ Felipe Sateler ]
  * Change maintainer address to debian-multimedia@lists.debian.org

  [ Joachim Bauch ]
  * Imported Upstream version 1.0.3
  * Update patches for new upstream version.
  * Update symbols for new upstream version.
  * Update standards version and switch to debhelper 10.

[dgit import unpatched libde265 1.0.3-1]

Import libde265_1.0.3.orig.tar.gz

[dgit import orig libde265_1.0.3.orig.tar.gz]

Import libde265_1.0.3-1.debian.tar.xz

[dgit import tarball libde265 1.0.3-1 libde265_1.0.3-1.debian.tar.xz]

Merge libde265 (1.0.2-2+rpi1) import into refs/heads/workingbranch

Merge libde265 (1.0.2-2) import into refs/heads/workingbranch